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Duplex Direct Data Distribution System 

Science Applications International Corporation 
San Diego, California 92121 


1. INTRODUCTION 

This report presents a set of end-to-end system concepts for implementing a Duplex Direct Data 
Distribution (D4) system. The D4 system is intended to provide high-data-rate commercial direct 
communications service between the National Aeronautics and Space Administration (NASA) 
spacecraft in low earth orbit (LEO) and the respective principal investigators (Pis) associated 
with these spacecraft. Candidate commercial services were assessed regarding their near-term 
potential to meet NASA requirements. Candidates included Ka-band and V-band geostationary 
orbit (GSO) and non-geostationary orbit (NGSO) satellite relay services and direct downlink 
(“LEO teleport”) services. Four realistic, near-future concepts were analyzed based on specific 
selected candidate services: 

• A direct link (uplink plus downlink) between a LEO spacecraft and a miniature 
autonomous earth station 

• A space-based relay based on a future Ka-band NGSO satellite system 

• A hybrid link using both direct and relay services to achieve full duplex capability 

• A dual-mode concept consisting of a direct and a relay link operating independently. 

The concepts were analyzed in terms of contact time between the NASA spacecraft and the 
communications service and the throughput that could be achieved. Cost estimates were also 
performed. The throughput and cost estimates were used to compare the concepts. 

1 .1 Requirements 

The concepts for implementing a D4 system are required to meet certain specific NASA 
requirements. The D4 system will support NASA mission spacecraft in LEO and will have the 
following characteristics: 

Rl. The system will utilize one or more commercial satellite communication (SATCOM) 
services. 

R2. The services will be available within 5 years (2005). 

R3. The services will operate at Ka-band or higher frequency. 

R4. The system’s links will be full duplex. 

R5. The system will support the use of Transmission Control Protocol (TCP) and Internet 
Protocol (IP). 

R6. The system will support a data rate of up to 622 Mbps in the return direction. 

R7. The system will support symmetric and asymmetric traffic on the link. 
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1.2 Assumptions 

Al. Missions: The NASA LEO missions are assumed to be those compiled in a previous 
Science Applications International Corporation (SAIC) report [IOAT], which consists of NASA 
missions for the years 2000 to 2010. For the purposes of this study, we ignore the fact that these 
missions may not be equipped with Ka-band communications capability. 

A2. Coverage and Latency: It is assumed that the system will not require global coverage and 
that some level of tolerance of latency is acceptably. In general, the commercial services with 
global coverage or global coverage except the poles are considered to provide low latency. Other 
services provide significantly less coverage and are considered to result in relatively high latency 
(some significant fraction of an orbital period or more) because of the need to store data onboard 
in parts of the orbit where coverage is not available. 

A3. Deployment: The services will be assumed to be available by 2005 if they are currently at 
least under development and have a planned first launch at least 1 year prior to 2005. If no 
deployment information is available, the service will be assumed not to be available by 2005. 

A4. Altitude: It is assumed that the satellites belonging to the commercial SATCOM service 
are above LEO altitude with their antennas pointed downward. It is assumed that other antennas, 
such as inter-orbit and inter-satellite links (ISLs), will not be available to a user of the service. 

A5. Protocols: It is assumed that NASA will use commercial off-the-shelf (COTS) applications 
and, therefore, that the TCP and IP protocols used by the D4 system should be COTS to the 
maximum extent possible. 

A6. Regulatory: It is assumed that the system must conform to International 
Telecommunications Union (ITU) regulations concerning mobile terminals. For example, use of 
a Mobile Satellite Service (MSS ) would be in compliance, whereas use of a Fixed Satellite 
Service (FSS) would not be. However, use of an FSS by a spacecraft for receive only (i.e., the 
mission spacecraft does not transmit) would be in compliance. 

Costing Assumptions 

Our approach to cost estimation was to assume that each concept would be implemented as a 
commercial service that would charge a usage fee that is a function of data rate. We did not carry 
out a bottom-up cost analysis incorporating engineering, infrastructure, operations, maintenance, 
and other elements that would be used by the system provider to derive their pricing. The 
bottom-up approach is beyond the scope of the current study. 

For satellite services that do not yet exist, we assumed that they will be priced to compete with 
similar terrestrial services. This is based on the fact that these services will compete head-to- 
head with terrestrial services in the same broadband market. For example, the Chief Executive 
Officer (CEO) of Spaceway stated that Spaceway will be priced to cost less than the equivalent 
terrestrial service. “We will not only deliver a rich mix of services but also sell bandwidth on 
demand — speed and capacity as you need it, when you need it — and at a cost that’s likely to be 
20-30 percent lower than the costs of competing land-based services such as frame relay.” 
[KAUL]. 
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Currently, most terrestrial wide area networks (WANs) are implemented as virtual private 
networks employing technologies such as frame relay and asynchronous transfer mode (ATM), 
and this is what we used for our cost model. These services are available with pricing based on 
either a usage rate or a flat rate. The basic approach for the cost model was to start with a 
baseline flat rate per month and then, for the usage-based model, divide by the number of 
minutes per month to get a cost per minute. 

A market survey of frame relay and ATM prices conducted in 1999 is described in [WELL]. This 
source summarizes the results by stating the prices of high data rate services as multiples of the 
basic T1 price. We adopted this approach and used the following relative cost formulas: 

• Cost of DS-3 (45 Mbps) = 5 times the cost of T1 (1.544 Mbps) 

• Cost of OC-3 ( 1 55 Mbps) = 1 .5 times the cost of DS-3 

• Cost of OC- 1 2 (622 Mbps) = 2 times the cost of OC-3. 

Finally, a cost for the baseline T1 is assumed. A survey of T1 price quotes on the Internet shows 
a wide range of values, from less than $500 per month up to $2,000 per month, or $0.0 1 2 to 
$0,046 per minute. 

The above assumptions result in the values for terrestrial rates shown in Table 1 - 1 . 


Table 1-1. Terrestrial Rates 


Data Rate 

Cost per Minute 

T1 (1.544 Mbps) 

$0.01 2 -$0,046 

DS-3 (45 Mbps) 

$0.06 -$0.24 

OC-3 (155 Mbps) 

$0.09 -$0.36 

OC-12 (622 Mbps) 

$0.18 -$0.72 


The NASA Direct Data Distribution (D3) Ka-band downlink system was developed for high data 
rate downlink service. Because there exist commercial services that are currently quoting prices 
for this type of service at X-band, we used these as a basis for estimating the cost of a service 
using the D3 equipment. 
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2. SYSTEM CONCEPTS 


The Statement of Work called for the development of a set of system concepts driven by the 
selection of a set of commercial SATCOM services. For each selected commercial service and 
corresponding concept, there would be three modes of communication: (1) between a LE O 
mission platform and the service to the service’s ground stations, (2) between a LEO mission 
platform and the service to the PI through a terrestrial network, and (3) between the LEO mission 
platform and the PI directly. However, we found that there were two fundamental types of 
commercial service: (1) the direct, or line-of-sight service, and (2) the SATCOM relay service. 
These are distinguished primarily at the link and physical layers. We chose to pursue the analysis 
using space-ground links as the fundamental element. 

The result of this approach is that the problem is decomposed somewhat differently than 
envisioned by the Statement of Work. Instead of selecting a set of concepts each having the three 
modes described above, we defined the concepts in terms of single and multiple mode categories. 
Within the single mode category, there were three space-ground link architectures: direct, relay, 
and a hybrid of the two. Multiple mode concepts then can be generated as combinations of the 
single mode types. Among the multiple mode possibilities, we examined a dual mode concept. 
The classification then looks as follows: 

• Single mode: 

- Direct (line of sight) 

> Simplex 

Uplink (to the mission spacecraft) 

Downlink (from the mission spacecraft) 

> Full duplex 

Symmetric 

Asymmetric 

- Relay 

> Simplex 

Forward (to the mission spacecraft) 

Return (from the mission spacecraft) 

> Full duplex 

Symmetric (equal data rate in both directions) 

- Asymmetric (different data rate in each direction) 

- Hybrid 

> Full duplex (e.g., simplex direct + simplex relay) 

Symmetric 

Asymmetric 

• Dual Mode: 

- Direct + relay, for example 

• Three-Mode: 

- Direct + relay + relay, for example. 

The end-to-end system can be decomposed into a terrestrial network component and a space-to- 
ground component. The terrestrial network component can be implemented using standard 
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TCP/IP networks and can be decoupled from the space-to-ground component. The decoupling or 
partitioning may be accomplished at the IP layer using gateways with Border Gateway Protocol 
operating between the terrestrial and space network gateways, as described in [IOAT]. 

Additional partitions may be required at the TCP layer, depending on whether or not TCP needs 
to be optimized for higher performance. The architecture at the higher layers, that is, at the IP 
and TCP layers, is driven in part by characteristics at the lower layers. For example, the 
bandwidth-delay limitation of TCP (see Section 3) and the means of improving it will depend in 
part on the propagation delay at the physical layer. 

2.1 Direct Link Concept 

The direct link architecture is defined as a line-of-sight wireless link between the mission 
spacecraft and an earth station. The link may be simplex, as in the case of the D3 experiment, or 
full duplex, as in the case of a duplex extension of D3, called D4. We studied the full duplex 
case, which is illustrated in Figure 2-1. The direct concept assumes the use of the D3 Ka-band 
dual beam 622 Mbps phased-array spacecraft antenna and transmitter and its associated receive 
earth station to achieve a direct downlink. In addition, it assumes a co-boresited or integrated 
spacecraft receiver and earth station transmitter for a direct uplink. The direct link may be 
symmetric (traffic capacity is the same in both directions) or asymmetric (traffic capacity is 
different in each direction). The asymmetric case is illustrated in the figure. 

2. 1. 1 Candidate Services 

There are several companies providing turn-key ground-station service, as shown in Table 2- 1 . 
These companies currently provide service at S-band and X-band, but Universal Space Network 
(USN) and Allied Signal DataLynx have indicated a willingness to add Ka-band capability if 
requested. The intentions of Swedish Space Corporation are not known. With the addition of 
Ka-band capability, USN and DataLynx meet all of the requirements of Section 1 . 

2. 1.2 Concept of Operation 

This concept considers an end-to-end operational scenario that meets the objective of directly 
serving Pis with LEO mission data. From the user perspective, the concept allows a PI or other 
authorized individual located anywhere within the global Internet to access the Pi’s mission 
spacecraft whenever it is in contact with an earth station. Using COTS applications in a 
Windows, UNIX, or other COTS environment, the PI will be able to send commands to the 
experiment and receive limited outputs from the spacecraft in real time. However, due to the 
special requirements of TCP, to fully utilize the available bandwidth of the D3 hardware, high 
volume data from the spacecraft must be stored at an intermediate server before being made 
available to the global Internet. This is referred to as a store-and-forward architecture. 

Possible applications are video teleconferencing to the International Space Station (ISS) and high 
bandwidth streaming video from the ISS, as well as downloads of large imagery files from earth 
resources spacecraft. 
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MISSION 

SPACECRAFT 



Dotted line = ACKNOWLEDGMENT PATH 


Figure 2-1. Direct Link Architecture 


Table 2-1. Candidate Earth Station Services 


Direct Downlink 
CbhUMsi 

Status 

First 

Lftimch 

m 

§13 

Si 

ij^ii 


Universal Space Network 

Proposed 

N/A 

ma 

X 

N/A 



Allied Signal DataLynx 

Proposed 

N/A 

X 

X 

N/A 

X 

Note A 

Swedish Space Corp. 

Unknown 

N/A 



N/A 

X 

Note A 


Note A: Corporate web site is primary reference. 


Our analysis, based on the characteristics of the NASA-developed Ka-band space-ground 
communication system components, suggests that the spacecraft and earth station can maintain 
contact for a period of several minutes or more per intercept per earth station. Sequential 
intercepts by other earth stations serve to increase the total contact time for a single orbit. The 
concept is to deploy multiple low-cost autonomous earth stations in locations that optimize the 
contact time within a given geographic area, such as CONUS. The earth stations should have 
contiguous coverage patterns. As the spacecraft moves between earth stations, a virtual link is 
maintained as in a terrestrial cellular telephone system. Thus, as far as the user is concerned, the 
connection is continuous within the coverage area. This allows for the use of a connection- 
oriented protocol such as TCP. This is feasible as long as a mechanism such as Mobile IP (MIP) 
is used and, in addition, the gaps in coverage are small enough to ensure that TCP does not time 
out, as explained in the next paragraph and in Section 3. 
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IP, TCP, and Application Layer Architectures 

Because the spacecraft, acting as an IP host, is physically moving within the network, the routers 
within the network must be updated as to the location of the spacecraft. This function is 
provided by MIP, as discussed in Section 3. Using MIP requires that the portion of the network 
connecting the spacecraft to the ground is partitioned from the rest of the terrestrial network, as 
shown in Figure 2-2, because the rest of the network does not use MIP. Partitioning is 
accomplished by means of an IP layer gateway. 



To establish and maintain a virtual link using TCP, there is a requirement for acknowledgment 
packets to be received or the protocol will consider the connection to be broken. The TCP 
connection can be maintained across a hand-over between earth stations as long as the gap 
between data and corresponding acknowledgment packets is less than the TCP timeout constant. 
Thus, gaps in coverage must be less than this to maintain the connection. 

Another feature peculiar to TCP is that, to fully utilize the high bandwidth of the link, TCP must 
be optimized by tuning some of its parameters to values different from the default TCP settings 
resident in a typical Windows or UNIX desktop. Because TCP is an end-to-end protocol, both 
ends of the connection must have the same settings for maximum performance. This necessitates 
a partition by means of a gateway at the TCP layer for high data rate connections, as shown in 
Figure 2-3. Outside of the partition, it must be assumed that random users will have the default 
TCP settings, which will limit the data rate available to them. Their TCP connection must 
terminate at the gateway. Inside the partition, the spacecraft will use an optimized instance of 
TCP, and its connection will also terminate at the gateway. So there is no end-to-end connection 
between the user and the spacecraft for the high data rate connection. This means that files 
transferred from the spacecraft over the high data rate connection must be stored, however 
briefly, at the TCP gateway. Hence the need for a store-and-forward architecture. Note that the 


NASA/CR— 2001-211198 


7 




TCP gateway is functionally distinct from the IP gateway and may reside at both a different 
logical and physical location within the network. 



Thin line = LOW DATA RATE 


Thick line = HIGH DATA RATE 
Dotted line = ACKNOWLEDGMENT PATH 


Figure 2-3. TCP Layer Gateway 

On the other hand, for lower data rate communications, such as a web browser interface to the 
command and control functions of the spacecraft, or for “quick-look” downloads of compressed 
imagery, the gateway should not be needed because an optimized instance of TCP should not be 
needed. Therefore, the store and forward architecture need not apply to a command channel. 
This is illustrated in Figure 2-3 by the thin line bypassing the gateway. 

Multiple Access 

Occasionally, multiple spacecraft will be in the coverage area of a single ground site and must be 
accessed simultaneously. Because multiple spacecraft generally are in different directions of the 
sky and the antennas are high-gain antennas, each spacecraft must have a high gain beam 
dedicated to it. For mechanically scanned parabolic dishes, this implies multiple physically 
distinct terminals. Using phased arrays, such as on the D3 device, multiple beams per antenna 
are an option. For multiple independent earth stations operating simultaneously at the same site, 
spectrum or time sharing methods would have to be used to prevent interference. 

The design of the multiple access protocol and other aspects of the link protocol, such as link 
establishment and handover protocols, were not investigated in this study. 
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2. 1.3 Throughput Estimate 
Site Selection 

Based on the operational concept of a LEO ground network supporting globally dispersed Pis, 
two typical LEO missions were selected for detailed analysis: the ISS and a nominal polar orbiter 
in a 98.2° inclination sun-synchronous orbit. Simulations were run for these orbits to determine 
the line of sight contact time with representative earth station locations. A four-site network in 
CONUS serving the ISS orbit and a two-site network serving polar missions were chosen. 

Each of the CONUS sites was an existing government facility where a suitable terrestrial 
communications infrastructure was assumed to exist. The CONUS sites are Ellsworth Air Force 
Base (AFB), Fort Lewis, Hill AFB, and KI Sawyer AFB. Kennedy Space Center was also 
included in the analysis, to compare the results at a lower latitude site. Because the number of 
contacts with the orbiter increases as the location of the earth station approaches the orbit’s 
inclination angle (highest latitude), site selection emphasized higher latitudes. An optimization 
of the latitude to maximize contact time was not performed because this was done in earlier work 
by NASA Glenn Research Center (GRC). The CONUS sites were also chosen for contiguous 
coverage. 

The polar sites are Poker Flats, Alaska, and Spitzbergen, Svalbard, where X- and S-band service 
to polar missions is already provided. Wallops Island was included in the analysis for 
comparison to a lower latitude site. 

The concept can be extended to other geographic deployment patterns than the ones discussed 
here. For example, for non-polar missions, it may be desirable to have a global distribution of 
earth stations to more evenly distribute the contact events and minimize storage onboard the 
spacecraft. 

Contact Time Analysis 

Satellite Tool Kit (STK), Version 4.1, developed by Analytical Graphics, Inc., was used for the 
calculations and the geographical depictions of the results. Each location was analyzed for 
contact times over a 10-day period, from which daily and per-pass averages were determined. 

The average daily throughput per site was calculated as the product of the average contact time 
and the data rate. Throughput was calculated only for the return side of the link. Depending on 
the degree of overlap between sites, the throughput for multiple sites considered as a single 
system may be roughly approximated as the sum of the throughputs for each site. 

The spacecraft was assumed to have a phased-array antenna with a conical beam scan capability. 
The spacecraft downlink antenna was assumed to be able to scan from a maximum angle away 
from the antenna boresite (the antenna scan half-angle) to the same angle on the opposite side of 
the boresite. The antenna boresite is assumed to be always pointed at spacecraft nadir. Antenna 
scan half-angles of 42°, 50°, 60°, and 70° were simulated for the ISS orbit case. The earth station 
antenna is assumed to be able to scan from a minimum elevation angle above the horizon 
necessary for a clear line of sight to the same angle above the opposite horizon. Elevation angles 
of 5° and 10° were simulated. In the ISS case, the maximum antenna scan half-angle needed by 
the spacecraft to maximize contact with an earth station with a 5° elevation angle was 70°. For 
the polar orbit case, the maximum spacecraft antenna scan half-angle needed was found to be 
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64°. Thus, to determine a spacecraft scan angle requirement to maximize contact times with the 
earth station, orbit, receive locations, and minimum earth station, elevation angles must be 
considered. 

The period of observation was chosen to be 10 days to minimize any aberrations in results due to 
differing diurnal orbit characteristics. The average daily contact time for an earth station was 
defined by dividing the total contact time results by 10. 

The graphic outputs of the simulations are shown in Figures 2-4 to 2-9. Summary results of the 
analysis are presented in Tables 2-2 and 2-3. 

2. 1.4 Cost Estimate 

A rough order of magnitude cost was estimated based on current commercial rates for similar 
services. USN is a provider of X-band direct downlink service at rates up to 300 Mbps. 
DataLynx from Allied Signal is another LEO teleport service. It operates an X-band station in 
Alaska and is allied to other partners worldwide, such as Swedish Space Corporation, which 
operates stations at far northern latitudes. Data rates are comparable to USN. These companies 
currently quote rough-order-of-magnitude prices in the range from $5 to $15 per minute, with a 
one-time engineering charge of approximately $150,000. The per-minute and one-time charges 
will probably decrease as more customers use the services and as usage grows. 

For a future Ka-band system operating at 622 Mbps, we assumed that the cost will be in the same 
range even at the higher data rate due to the use of smaller, lower cost earth stations, combined 
with decreasing prices over time and a steep discounting curve with respect to bandwidth. 

2. 1.5 Spectrum Considerations 

Selection of suitable Ka-band frequencies for the direct link concept should be studied with 
respect to susceptibility to interference and equipment compatibility with Tracking and Data 
Relay Satellite System (TDRSS)-H, I, and J RF equipment and commercial radio frequency (RF) 
equipment. Federal Communications Commission or National Telecommunications and 
Information Administration (FCC/NTIA) and ITU filings for the selected Ka-band frequencies 
should then follow. 

Figure 2-10 summarizes the Ka-band frequency allocation to different services and orbits, 
according to the ITU. The NASA Ka-band direct links may qualify for the 500-MHz MSS/ 
NGSO band (uplink: 28.6 to 29.1 GHz and downlink: 18.8 to 19.3 GHz) that is shared with the 
Teledesic system. 

The NASA Ka-band direct link may also qualify for the earth exploration satellite services 
(EESS) band, shown in Figure 2-10. As far as priority is concerned, EESS is secondary to other 
services shown in the figure. A suitable selection may be a 100-MHz band from 28.5 to 28.6 
GHz for uplink and a 200-MHz band from 18.6 to 18.8 GHz for downlink. 
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Figure 2-4. Five Stations Used in ISS Orbit Simulation 



Figure 2-5. ISS Orbit Contacts, 42° Scan Angle 
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Figure 2-6. ISS Orbit Contacts, 60° Scan Angie 



Figure 2-7. ISS Orbit Contacts, 70° Scan Angie 
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Figure 2-8. Three Stations Used in Polar Orbit Simulation 



-135-120-105 -90 -75 60 -45 ^30 -15 0 15 pO 45 60 75 00 105 120 135 750 16' 

Figure 2-9. Polar Orbit Contacts 
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Table 2-2. Summary of Contact Times 
for the ISS Orbit with Five Earth Stations 


1 

51.6® Incl 

- 404 Km Altitude (Circular) 



Earth Station Location 


KiBaH 

10-Day Total 
(seconds) 

42 

Ellsworth AFB 

5 or 10 

84.0 

1,344 

Fort Lewis 

5 or 10 

86.2 

1,896 

Hill AFB 

5 or 10 

85.4 

1,196 

Kl Sawyer AFB 

5 or 10 

88.8 

1,776 

Kennedy SC 

5 or 10 

86.3 

776 

50 

Ellsworth AFB 

5 or 10 

115 

2,643 

Fort Lewis 

5 or 10 

109 

3,817 

Hill AFB 

5 or 10 

116 

2,212 

Kl Sawyer AFB 

5 or 10 

112 

3,366 

Kennedy SC 

5 or 10 

110 

1,430 

60 

Ellsworth AFB 

5 or 10 

176 

7,024 

Fort Lewis 

5 or 10 

201 

9,031 

Hill AFB 

5 or 10 

177 

5,472 

Kl Sawyer AFB 

5 or 10 

193 

9,059 

Kennedy SC 

5 or 10 

181 

3,446 

70 

Ellsworth AFB 

5 

445 

28,021 

Ellsworth AFB 

10 

343 

19,867 

Fort Lewis 

5 

446 

27,228 

Fort Lewis 

10 

355 

19,520 

Hill AFB 

5 

432 

27,930 

Hill AFB 

10 

307 

18,712 

Kl Sawyer AFB 

5 

452 

27,546 

Kl Sawyer AFB 

10 

358 

19,665 

Kennedy SC 

5 

391 

17,205 

Kennedy SC 

10 

306 

10,393 
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Table 2-3. Summary of Estimated Contact Times 
for a Polar Orbit with Three Earth Stations 


| 98.2 0 inclination - 705 Km Altitude (Circular) i 

Spacecraft Antenna 
Scan (”) 

Station Location 

Elevation Angle (’) 

Mean Duration 
(Seconds) 

10-Day Total 
(Seconds) 

42 

Poker Flats 

5 or 10 

159 

3,659 

Spitzbergen 

5 or 10 

177 

10,463 

Wallops Island 

5 or 10 

179 

1,785 

50 

Poker Flats 

5 or 10 

215 

7,084 

Spitzbergen 

5 or 10 

247 

16,814 

Wallops Island 

5 or 10 

219 

3,295 

60 

Poker Flats 

5 or 10 

360 

22,288 

Spitzbergen 

5 or 10 

417 

38,349 

Wallops Island 

5 or 10 

385 

10,011 

64 

Poker Flats 

5 

568 

52,295 

Poker Flats 

10 

429 

36,433 

Spitzbergen 

5 

590 

77,270 

Spitzbergen 

10 

492 

53,080 

Wallops Island 

5 

536 

22,518 

Wallops Island 

10 

440 

14,970 
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Figure 2-10. ITU Allocations in the Ka-Band 


From general interference considerations, sharing with the FSS/NGSO (e.g., Teledesic), as 
opposed to sharing with the FSS/GSO (e.g., Spaceway), will result in more interference, and the 
coordination will be more difficult. 

NASA should also consider using the same Ka-band frequencies that the TDRSS-H, I, and J 
satellites will operate on (the ISL return link: 25.25 to 27.50 GHz and ISL forward link: 22.55 
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to 23.55 GHz) if it is acceptable to FCC/NTIA and ITU. It will be simpler to share with GSO 
satellites and to perform coordination within NASA. 

Teledesic is not likely to be deployed within the next several years. Accordingly, the FSS/NGSO 
Ka-band should be treated as the primary candidate. Note also that if Teledesic or Teledesic-like 
systems were deployed, one could still implement the concept by placing earth stations in 
unpopulated areas where Teledesic does not have any customers other than the backhaul links 
associated with the earth stations; therefore, coordination would be straightforward. 

2. 1.6 Technology Considerations 

The Ka-band transmitter and receiver developed for the D3 project would have to be augmented 
with an uplink transmitter and receiver to provide full duplex operation to operate using the TCP 
protocol. The minimum uplink data rate required would have to be at least sufficient to carry the 
acknowledgments generated by the 622 Mbps downlink. In Section 3.3, this issue is analyzed, 
and the results of a simplified simulation are discussed. 

The uplink system would operate at 29 GHz, assuming that 19 GHz is the downlink frequency. 
This would include a receive phased array on the spacecraft and a transmitter and tracking dish 
on the ground. A 1 -meter or less sized dish appears to be feasible for the asymmetric case. 

Using these assumptions, point designs were done for the uplink for the asymmetric and 
symmetric cases. These are shown in Table 2-4. 

The purpose of the concept discussed in this section is to extend the performance of the D3 
system, including increased contact time per earth station. One way of accomplishing an 
increase in contact time capability by means of an increase in scan angle would be to mount four 
phased array antennas side by side at 90° with respect to each other. Unfortunately, this would 
also require an increase in transmitter power to accommodate the greater slant range, all other 
parameters being equal. For comparison, the current state of the art for solid state power 
amplifiers is approximately 6 watts [UHM]. 

Table 2-4. Point Design Link Budgets for D4 Uplink (705 km Altitude) 


Parmwiar 

ajniiitsu tv 

Case 

Asymmetric 

Owe 

Frequency (GHz) 

29 

29 

Data Rate (Mbps) 

622 

0.256 

Data Rate (dB) 

87.9 

54.1 

Eb/No 

8.2 

8.2 

Gs 

20 

20 

Ts (500° K) 

27 

27 

Gt (1 meter) 

48.1 

48.1 

Losses (rain+gas) (dB) 

16 

16 

Boltzmann’s constant (dB) 

-228.6 

-228.6 

Free space loss 

189.1 

189.1 

Terminal Power (dBW) 

31.5 

-2.3 

Terminal Power (W) 

1412 

0.59 
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2.2 Space Relay Concept 

The space relay link architecture is defined as a system that uses a satellite relay service to link 
the mission spacecraft to an earth station, as illustrated in Figure 2-11. It shows a full duplex 
forward TCP connection and a full duplex return TCP connection over the same physical 
channel. The asymmetric case is shown, in which the forward connection, for command and 
control, has a low data rate, and the return connection, for science data, has a high data rate. 
Because TCP connections are illustrated, the respective acknowledgment streams are also 
represented. 



Dotted line = ACKNOWLEDGMENT PATH 


Figure 2-1 1 . Space Relay Architecture 
2.2. 1 Candidate Services 

Commercial SATCOM services that operate in full-duplex mode fall into two general categories 
of ITU-defined services: MSS and FSS. These categories are further defined by their orbits: 
either GSO or NGSO. Examples of these categories with some nominal characteristics are 
shown in Table 2-5. 

Existing and proposed SATCOM services relevant to this application were identified and listed 
in Table 2-6. The evaluation criteria are based on the requirements and assumptions in Section 1 . 
The table shows the compliance of each candidate with respect to the evaluation criteria. The 
first two columns, status and first launch , are not criteria but were used to derive likelihood of 
deployment by 2005 in accordance with assumption A3 in Section 1 . 
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Table 2-5. Space Relay and ITU Services 


Architecture 

Spacefteiay | 

ITU Designation 

MSS GSO 

MSS NGSO 

FSS GSO 

FSS NGSO 

Example 

Spacehab/lnmarsat 

New ICO 

Hughes Spaceway 

TRWGESN 

Coverage 

Global except for poles 

Global visibility 

Regional spot beams 

Global visibility; spotbeams 

Frequency 

L-band 

L-band 

Ka-band 

Ka-, V-bands 

Forward Data Rate 

64 kbps 

Unknown 

10’s to 100’s of Mbps 

10's to 100’s of Mbps 

Return Data Rate 

64 kbps 

-100 kbps 

10’s of Mbps 

10’s to 100’s of Mbps 

Orbit 

GEO 

MEO 

GEO 

MEO and GEO 

Latency 

Real time 

Real time 

Hours or days 

Real time 

Service Start Date 

2003 

2003 

2002 

After 2010 


Selection Results 

None of the candidates among the SATCOM services meets all of the criteria. Most Ka-band 
and V-band systems are either in the FSS category, and therefore ruled out on regulatory grounds, 
or are at this time merely “paper satellites,” proposals with little likelihood of deployment 
[FOL1]. Assuming that one or more criteria could be relaxed, potential candidates in each 
category are discussed below. 

MSS GSO 

SAIC found in the Integrated Operations Architecture (IOA) study [IOAT] that Inmarsat was a 
realistic candidate for supporting NASA missions, even though it operates at L-band. Inmarsat is 
currently and for the near future one of the few near-global MSSs. It has definite application to 
NASA missions for low data rate communications such as Telemetry, Tracking, and Command 
(TT&C). It could be used by a PI to send commands to a spacecraft, but because it has such a 
low data rate, it has limited application for large file transfers from the mission platform. 

Because of the near-global nature of the service, it can be used for latency-sensitive applications, 
unlike almost all of the other SATCOM services discussed in this report. Another advantage is 
that Spacehab is developing a space-qualified terminal to operate with Inmarsat and is planning 
to provide this service commercially [SHAB]. 

MSS NGSO 

In the MSS NGSO category, New ICO appears to be the only near-term candidate. It does not 
operate at Ka-band, nor will it have megabit-per-second capacity. In the longer term, there is 
StarLynx, a medium earth orbit (MEO) system. StarLynx is a V-band system. It is considered to 
be a “paper satellite,” and skepticism regarding the V-band systems is even greater than for the 
Ka-band satellites. See, for example, [FOL1]. If we ignore the probability of the system being 
deployed, it appears to best meet the requirements of all the candidates. Because little is known 
about its design, it is hard to assess the feasibility of interfacing with a LEO spacecraft. On the 
other hand, because the deployment is so far in the future, there is time for NASA to influence 
the design. 
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Table 2-6. Candidate SATCOM Services 


Candidates 
MSS GSO 

Spacehab/lnmarsat 

Inmarsat 1-4 

Inmarsat Horizon 
Boeing Connexion Ku 
Boeing Connexion Ka 
Hughes StarLynx 
MSS NGSO 

New ICO 

Globalstar 

Hughes StarLynx 

FSS GSO 

SES Astra 

Hughes Spaceway 

LM Astrolink 

EuroSkyWay 

Wild Blue (iSky) 
TetesatANIK F2 
Loral Cyberstar 
Matra Marconi WEST 

CAi Satcom 

Hughes Expressway 
Hughes SpaceCast 
Loral CyberPath 
Spectrum Astro Aster 
PanAmSat V-Stream 
LM Q/V Band 

GE StarPlus 

FSS NGSO 

Alcatel SkyBridge 
Boeing NGSO FSS 
HughesLINK 

HughesNET 

Teledesic Ku Suppl. 
Virtual GEO Sat 

Teledesic 

©Contact 

LM-MEO (Ka) 

Skybhdge 11 

Spaceway NGSO 
Teledesic VBS 
OSC OrbLink 
Denali Pentriad 

GE StarPlus 

Globalstar GS-40 
LMMEO(V) 

TRW GESN 


First Available Ka-Band MEO Orbit Regulatory 
States Launch by 2005 or Higher or Higher Compliance Reference 


Under dev, 2003 


Under dev. 


Proposed 


Under dev. N/A 


Proposed 2005 


Proposed | 2005 


Under dev. 

2001 

Deployed 

deployed 

Proposed 

2005 


Deployed deployed 


under dev. 2002 


under dev. 2003 


under dev. 2002 


under dev. 2001 


under dev. 2002 


proposed 


proposed 


proposed 


proposed | 2005 


proposed 


proposed 


proposed 


proposed 


proposed 


proposed 


under dev 


proposed 


proposed 


proposed 


proposed 


proposed 


proposed 


proposed 


proposed 


proposed 


proposed 


proposed 


proposed 


proposed 


proposed 


proposed 


proposed 


proposed 



[AWST] 


[SPAC] 


[LLST] 


[LLST] 


[LLST] 


[TSAT] 


[LLST] 


[AWST] 


[TRW1] 


[FAA1] [TRW1] 


[TRW1] 


[TRW1 } 


[TRW1] 


[TRW1] 


[TRW1] 


[TRW1] 





[FAA1] 


[FAA1] 


[FAA1] 




[FAA1] [TRW1] 


[FAA1] [TRW1] 


[FAA1] [TRW1] 
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FSS GSO 


The FSS candidates were ruled out based on the regulatory problem of a mobile terminal 
interfacing to a fixed service. This problem is beyond the control of NASA, so the criterion 
cannot be “relaxed.” 

Even if the regulatory problem could be solved, there are major technical problems when 
interfacing to the new generation of onboard processed, dynamically assigned, spot-beam 
satellites. As a case in point, SAIC investigated the Spaceway system to a level of detail 
sufficient to determine that it cannot be made to interoperate with a moving spacecraft. The 
Spaceway beams are too narrow, so the contact time is too short to allow appreciable data 
transfer and perhaps too short to establish the link. The network operating system is designed to 
have constant contact with earth stations, which are assumed to be located at fixed positions. 

There are other Ka-band satellites that are bent-pipe systems and have broader beams than 
Spaceway. An example is the ANIK F2 satellite. Unlike the case of Spaceway, interfacing with 
these systems may be technically feasible. 

FSS NGSO 

Broadband NGSO systems have the potential to provide global coverage. Unfortunately, the 
regulatory problem rules out the FSS NGSOs, including Teledesic. In addition, there is 
skepticism as to the likelihood of their deployment. 

The Federal Aviation Administration (FAA) model [FAA1] posits two scenarios for the proposed 
NGSO systems in the 2000-2010 time frame: an optimistic one and a pessimistic one. The 
optimistic one is for two broadband NGSO systems to be deployed, and the pessimistic one is for 
only one to be deployed. This rather negative picture implies that most of the proposals are in 
reality “paper satellites” that will never be deployed. The NGSO system that is probably closest 
to deployment is Skybridge, which is a Ku-band system. Based on the literature surveyed for this 
report, we rate the probability of operational deployment of the systems in the “proposed” 
category as very low. 

There are significant business risks faced by these systems. [NOLL] lists the risks as: 

• The satellites spend 70 percent of their time over the earth’s oceans and thus are not 
usable for much of their life. 

• The many years needed to design, manufacture, and launch the satellites mean that the 
technology is nearly obsolete by the time it is finally placed in orbit. 

• The radio bands used for the communication are line-of-sight and do not work indoors, 
in the shadows of buildings, or under trees. 

• The enormous initial investment for the large number of satellites means that the initial 
service may be very costly. 

According to [CROS], only four broadband Ka-band systems have a high probability of going 
into service in the United States in the next 3 to 5 years. They are Hughes Spaceway, Loral 
Cyberstar, Lockheed Martin Astrolink, and Teledesic. In our opinion, Teledesic will not be 
deployed in that time frame because the chief investor and builder, Craig McCaw, will wait to 
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see how New ICO performs before proceeding with Teledesic. Also, Teledesic does not 
currently appear to be under development. The recent selection of a new prime contractor 
indicates that the design must start again from the beginning. 

Inter-Satellite Service Approach 

It should be mentioned that many of the above services will have ISLs, which operate under the 
ITU classification of Inter-Satellite Service. Theoretically, a NASA spacecraft could interface to 
a commercial ISL without regulatory conflict. However, the design of the ISL hardware would 
have to be changed to accommodate the different tracking requirements of a LEO spacecraft. 
Other internal system design details would have to change as well. This implies that NASA 
would have to be a partner with the commercial provider early in the design stage of the 
commercial system. It is unlikely that this could be done for systems that will be deployed by 
2005. 

If the design of the ISLs of one of the commercial MEO systems could be modified to 
accommodate NASA requirements, presumably the main spot beam tracking subsystem could be 
modified as well. For example, the MEO satellite could be commanded to track a NASA 
platform over the ocean, where service is not otherwise provided and where interference with 
other users is minimal. 

2.2.2 Concept of Operation 

Given that the FSS systems must be ruled out on regulatory grounds and the near-term MSS 
systems do not operate at Ka-band, the most viable candidate for this architecture appears to be 
Hughes StarLynx. StarLynx is an MSS that has a GSO and an NGSO (MEO) component. 
Therefore, a notional MEO constellation based on StarLynx was assumed. For example, the 
MEO orbit is assumed to be 10,000 km at an inclination of 55°. 

The architecture allows the NASA LEO spacecraft to communicate directly with the MEO relay 
spacecraft. NASA data would be relayed to the MEO satellite when LEO-to-MEO connectivity 
could be established. The relayed data may be directly received by a Pi's earth station, or the 
data may be received at a gateway facility. In the latter case, either the Internet or other terrestrial 
means will be necessary to connect the user to the gateway. 

2.2.3 Throughput Estimate 

Lacking technical details of the StarLynx design, some simplifying assumptions were made to 
estimate throughput. It is assumed that the MEO constellation will provide continuous coverage 
to mobile terminals and that the mobile terminals can roam anywhere in the service area. We 
further assumed that NASA would be able to influence the design such that the serv ice area 
covers the entire area visible to the satellite spot beams. Then for LEO missions below a certain 
orbital inclination, global coverage would be available. Assuming that contact with the service is 
available for a nominal 80 percent of the day, the contact time would be 69, 1 20 seconds per day. 

StarLynx is stated to provide a 2 Mbps data rate using a 1-foot diameter terminal antenna and 
8 Mbps using a 2-foot diameter terminal antenna [TRW1]. Using the 8 Mbps value, the 
throughput per day is 553 gigabits. 
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2.2.4 Cost Estimate 

The pricing for services such as StarLynx will likely be set to compete with terrestrial broadband 
service. The cost estimate, therefore, can be estimated based on terrestrial service. We assume 
present-day prices. From our cost assumptions (Section 1), the cost of T1 ranges from $500 to 
$2,000 per month, or $0,012 to $0,046 per minute. We assume that the cost of 8 Mbps service is 
two times the cost of T1 service, or $0,024 to $0,092 per minute. 

2.2.5 Spectrum Considerations 

Currently, the relay communication services provided by NASA are categorized by the ITU as 
Space Research Service (SRS), Space Operation Service (SOS), and Inter-Satellite Service. For 
example, the TDRSS H, I, and J satellites will provide Ka-band service under the Inter-Satellite 
Services category. On the other hand, commercial satellite communication services available 
now or in the foreseeable future are FSS, Broadcast Satellite Service (BSS), and Radio- 
Determination Satellite Service (RDSS). All candidate commercial satellite services are either 
MSS or FSS. The Ka-band FSS allocations are different from the Ka-band Inter- Satellite Service 
allocations, as shown in Figure 2-10 in Section 2.1.5. 

Thus, technically, by using commercial satellite services to meet relay communication 
requirements by LEO spacecraft, NASA would be in non-compliance with the ITU. Such non- 
compliance usage may be acceptable if NASA could show that the usage would not cause 
harmful interference to other systems. In the past, similar non-compliance usage has occurred 
[VUON]: 

• To promote the Direct Broadcast Satellite (DBS) service, the FCC in 1987 allowed 
partial usage of the BSS Ku-band for FSS [FCC]. 

• The FCC allowed Qualcomm to use a FSS Ku-band transponder of a Gstar satellite for 
its OmniTracs service, which is MSS, on a non-interference basis (i.e., if harmful 
interference is detected, the service must be stopped) [NICH]. 

• Intelsat and COMSAT (not the ITU) allowed the Navy to use CSCI/Intelsat’s FSS C- 
band global transponders on a non-interference and experimental basis for the 
Challenge Athena project, which is MSS [HEAR]. 

• Hughes Communication Inc. (HCI) (not the ITU) has also allowed the Defense 
Airborne Reconnaissance Office (DARO) to use CSd/HCI’s FSS Ku-band 
transponder on a non-interference and experimental basis for relay communication 
testing of its unmanned aerial vehicles (UAVs), which are MSS [SMIT]. 

2.2.6 Technology Considerations 

To use the Inmarsat MSS GSO service, no new technology would be needed, assuming 
Spacehab, Inc., is successful in developing this service. As reported in [IOAT], Spacehab is 
developing the space-qualified terminal for use with Inmarsat. 

To use StarLynx, a full-duplex spacecraft terminal would have to be developed at V-band. It 
may be noted that Hughes plans to develop a tracking phased array antenna for the mobile user 
terminals for this service. 
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To use an ISL interface to one of the NGSO systems, the spacecraft terminal would have to be 
either an RF terminal, most likely at V-band (extremely high frequency [EHF]), or an optical 
terminal. One advantage of the ISL approach is that the same technology could be used on the 
NASA spacecraft as on the commercial satellite. 

If it is desired to use a Ka-band service, a full-duplex spacecraft terminal would have to be 
developed. An example of a Ka-band link budget was calculated for a LEO mission 
communicating with a GSO service. Table 2-7 summarizes a link power budget computed to 
support a data rate of 6 Mbps with an Eb/No of 8.2 dB from the NASA LEO satellite to a 
geosynchronous orbit (GEO) relay satellite. An Eb/No of 8.2 dB should be sufficient to achieve 
near-error-free operation with the proper selection of modulation and forward error correction, 
such as an inner convolutional code with an outer Reed-Solomon code. Assuming a 1.5° GEO 
beamwidth, a required a LEO equivalent isotropic radiated power (EIRP) of 52.6 dBW is 
computed. Assuming the 0.5° beam, a required LEO EIRP of only 43.6 dBW is obtained. As a 
point of reference, the NASA GRC Ka-band phased array is rated at 39 dBW at 19 GHz 
[WALD], Thus, a somewhat higher power space qualified phased array would be necessary to 
support 6 Mbps. The GRC space-based phased array can support 622 Mbps space-to-earth even 
accounting for atmospheric and rain losses, but in the example considered here, the LEO-to-GEO 
free space loss is so great (212.3 dB) that 6 Mbps is not achievable. Another phased array being 
developed by NASA (along with commercial partners) is specified to operate in the TDRSS 
bands (22.25-27.5 GHz) and generate an EIRP > 33 dBW [PELL], 

2.3 Hybrid Concept 

The hybrid category is defined as a system that uses different link types for the forward and 
return paths. In the commercial SATCOM world, hybrid architectures most often refer to a split 
link consisting of a forward path utilizing a relay satellite and a return path utilizing a landline. 

A good example that demonstrates the feasibility of the approach is Hughes DirecPC (first 
generation). This is a broadband Internet access service and is illustrated in Figure 2-12. 


Table 2-7. Link Power Budget Summary - NASA LEO to GEO Relay 


Parameter 


0.5» 

NASA LEO EIRP 

52.6 dBW 

43.6 dBW 

FSLup 

212.3 dB 

212.3 dB 

Pointing Loss 

0.5 dB 

0.5 dB 

Polarization Mismatch 

0.2 dB 

0.2 dB 

Demod Loss 

2.0 dB 

2.0 dB 

GEO Rx Gain (1 .5-) 

41 dBi 

50 dBi 

Data Rate 

6 Mbps 

6 Mbps 

Eb/No 

8.2 dB 

8.2 dB 
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RELAY SAT 



Figure 2-12. Hughes DirecPC Hybrid SATCOM Architecture 
2.3. 1 Concept of Operations 

In our case, use of a landline is not applicable. Instead we considered the case of using a direct 
downlink architecture for the return link and a space relay architecture for the forward link. This 
concept is illustrated in Figure 2-13. The direct downlink utilizes the D3 hardware. The forward 
data travels to the spacecraft via the space relay link, and TCP acknowledgments travel back to 
the ground via the direct downlink. The return data travels from the spacecraft to the ground via 
the direct downlink, and the TCP acknowledgments for this data travel back to the spacecraft via 
the relay service. The rationale for this architecture is that, because the TCP acknowledgments 
for the 622 Mbps downlink can be carried on a relatively narrowband channel, using a SATCOM 
relay service to carry these packets is a viable alternative to using a direct uplink. For example, 
because many spacecraft will carry S-band transceivers compatible with TDRSS, the TCP 
acknowledgment packet stream for the direct downlink could be carried back to the spacecraft 
through a TDRSS S-band channel. Another example would be to accomplish the same thing 
using the Spacehab Inmarsat transceiver. 

There are many variations within this architecture. The two links may be simplex or duplex. 
They may have differing or equal bandwidths (asymmetric and symmetric cases, respectively). 
The relay link may carry only acknowledgments, or it may carry additional user application 
channels such as command and control. 
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Dotted tine • ACKNOWLEDGMENT PATH 


Figure 2-13. Hybrid Architecture 

At least two variations appear to make sense for the application: 

• Simplex forward, simplex return 

• Duplex forward, simplex return. 

Examples are given in Table 2-8 along with the salient features of each. 


Table 2-8. Hybrid Architecture Examples and Features 


Architecture 

Hybrid | 

Subcategory 

Simplex forward, 
simplex return 


Duplex forward, 
simplex return 


Forward Data Path (FDP) 

Relay 


Relay 


Acknowledgment (ACK) Path for FDP 

Direct 


Relay 


Return Data Path (RDP) 

Direct 


Direct 


ACK Path for RDP 

Relay 


Relay 


Relay Path Implementation Example 

BSS: DirecPC 

FSS: 1-Way VSAT 

MSS: Inmarsat 

ISS: TDRSS S-band 

Direct Path Implementation 

D3 

D3 

D3 

D3 

Relay Frequency Band 

Ku 

Ku 

L 

S 

FDP Data Rate (Mbps) 

6 

35 

0.064 

0.256 

Coverage (Best Case) 

Continental 

Continental 

Global except poles 

Global except poles 

Propagation Delay 

GEO 

GEO 

GEO 

GEO 

Data Latency 

High 

High 

High 

High 
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Because this architecture only requires a simplex link over the relay path, BSS and FSS may be 
considered in addition to MSS. For example, a direct broadcast video satellite can be used to 
create the forward path of the link, as shown in the second column of the table. 

Note that the case of simplex forward/simplex return is compatible with ITU regulations for FSS 
and BSS. This is because the user (the NASA mission platform) does not transmit to the service; 
it only receives from the service. There are thus no interference issues. However, some FSSs 
may require a full duplex link to the service because the network operating system may need to 
communicate with the user terminal on a nearly continuous basis. 

The second column in the table shows a BSS used to provide a forward path for commands and 
also for TCP acknowledgments to the spacecraft. 

The third column in the table shows a one-way very small aperture terminal (VSAT) service as 
another way to create the same forward path. 

The fourth column in the table shows a near-global, mobile service, Inmarsat, used to create the 
forward path. It is a full duplex service, so packets may travel over the direct path or the relay 
path in the return direction. Unfortunately, it is a narrow-band service, so it limits the number of 
acknowledgment packets available to the TCP connection for the return path. An alternative 
approach would be to use the Inmarsat full duplex link for TCP/IP interactive communications 
with the spacecraft and a protocol other than TCP on the direct link. This is discussed in the next 
section as a combination architecture. 

The last column in the table shows TDRSS as the relay service, another way of achieving the 
same thing. Using this service has the advantage of being able to use an existing narrowband 
transceiver on the spacecraft. 

2.3.2 Throughput Estimate 

As in the previous concepts, throughput refers to the throughput in the return direction. That is, 
we considered only the asymmetric case for the throughput estimate. The throughput for this 
concept is theoretically the same as for the direct architecture because it would use the D3 
hardware for the return side of the system. However, the throughput could be limited to less than 
the capacity of the D3 if the relay service data rate is not sufficient to carry the TCP 
acknowledgment packets. This might be the case with Inmarsat, for example. 

2.3.3 Cost Estimate 

For the cost estimate, we assumed that the cost for the return link would be the same as for the 
direct architecture. The cost for the forward (relay) link falls in a broad range, depending on 
which service is assumed. We assumed the cost for the forward link would be $1.29 to $13 per 
minute, using the SOMO catalog prices for TDRSS MA service [SOMO]. 

2.4 Combination Concept 

There are many possible combinations of the basic direct and relay architectures. However, we 
considered only one, which might be called a dual-mode system in analogy to cellular telephone 
handsets that can access two different wireless systems. 
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NASA has expressed an interest in a system concept that would give a PI three optional methods 
of communicating with the Pi’s spacecraft through: 

1. A direct link earth station at the Pi’s site 

2. The Internet to a remotely located direct link earth station 

3. The Internet through a space relay satellite. 

From these three scenarios, we see that there are two basic link architectures involved: a direct 
link and a space relay link. Because the PI can establish a connection in any of the three 
scenarios, both link types must operate independently. Scenarios 1 and 2 are direct architectures, 
and scenario 3 is a space relay architecture. But because the links operate independently, it is not 
a hybrid architecture in our sense of the term. 

A direct link at the Pi's site (scenario 1 ) has the advantage of not requiring a high-bandwidth 
WAN connection. It also has the advantage that the local area network (LAN) maximum 
transmission unit (MTU) and the TCP maximum segment size can be configured to a large size 
to minimize the number of acknowledgments and thereby minimize the uplink data rate 
component of the full duplex link, as explained in Section 3.3. 

Scenario 2 is equivalent to the Direct Concept discussed in Section 2.1. There it was shown that 
TCP requires a partition between the private network that the spacecraft uses to connect to the 
earth and the public terrestrial Internet. This is to optimize TCP inside the partition to 
accommodate the high data rate of the link. (The optimization includes the use of an unusually 
large maximum segment size and MTU, as in scenario 1.) Thus, scenario 2 requires a store-and- 
forward architecture for the 622 Mbps connection. There is a gateway server where files must be 
stored before the PI can access them. Thus, scenario 1 allows real-time, direct 622 Mbps 
connection to the spacecraft by the PI, whereas scenario 2 does not. However, scenario 2 does 
not preclude a low data rate real-time connection in parallel with the high data rate store-and- 
forward path. It is possible to make the store-and-forward aspect invisible to the user in this 
manner. As far as the user can tell, there is real-time interactive contact with the spacecraft. 
However, some form of agent software would carry out the task of actual high-speed file 
transfers from the spacecraft. 

This approach lends itself to another, simpler, implementation, that is, to dispense with TCP for 
the direct downlink because end-to-end TCP cannot be used anyway. Instead User Datagram 
Protocol (UDP) could be used. Then a direct uplink would not be required because 
acknowledgments would not be required. TCP/IP would be used on the space relay link 
(scenario 3) for Pi-spacecraft interaction. Because this interactive application requires only a low 
data rate, a low data rate service such as Inmarsat or the TDRSS MA S-band service could be 
used. This concept is shown in Figure 2-14. 
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Figure 2-14. Dual Mode Concept 
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3. PROTOCOL CONSIDERATIONS 

In this section, we present some issues that arise with respect to TCP/IP and its planned 
deployment in NASA satellite mission payloads. The approach taken in this analysis relies on 
the initial selection of link layer scenarios that represent different types of communication 
between earth terminals and the mission payloads, which at this time are assumed to be operating 
at LEO. This a priori selection is presented in Section 2. Given the standard layering model used 
in designing and developing communications systems of today (and the Internet, in particular), 
we rely on a decoupling of link layer technology from the IP logical network. The IP network 
is also decoupled from the end-to-end transport layer, capable of ordered delivery and 
retransmissions due to packet loss. Finally, the Internet layering model decouples the application 
from the underlying transport layer. 1 

From these previously selected scenarios, we present the potential issues that arise when standard 
TCP/IP is used for end-to-end communication between a user (e.g., PI) residing in the terrestrial 
portion of the Internet and the target spacecraft payload. We also discuss another IP technology 
known as multicast, which can dramatically reduce bandwidth usage between an earth station and 
the satellite payload in cases of one-to-many communication. 

Pursuant to the request of NASA, an underlying goal in the following is to present issues as they 
relate to communication with standard TCP/IP protocols used on the Internet. We define 
standard TCP/IP as that version of the protocol that is bundled in operating systems such as 
Win98, Solaris, and Linux. In cases where standard TCP/IP is considered problematic, we 
present options that can address these concerns. We also follow the NASA request of focusing 
on end-to-end communication between users and the payload (versus store and forward designs), 
as well as NASA’s desire to rely as much as possible on Internet-related COTS products, which 
primarily rely on TCP as the underlying transport protocol. 

3.1 TCP Considerations 

On the Internet today, nearly 95 percent of all traffic carried by IP and traversing an Internet 
service provider (ISP) is TCP based. The other 5 percent is a mix of UDP and Internet Control 
Message Protocol (ICMP) — the former predominantly used for Domain Name Service (DNS) 
and name resolution, and the latter used to provide feedback (typically, echo requests) for 
network operators. 

3. 1. 1 Two-Minute Timeout 

In general, after a TCP connection is made, state information (that uniquely identifies the end-to- 
end connection) is retained until either the source or destination terminates the connection. 

Given this model, a TCP connection can exist indefinitely at both the source and destination 
hosts. One condition that can terminate the connection in an untimely manner is when the source 
has sent a packet and it has not received an acknowledgment within 2 minutes. Such a condition 
causes the source to view the destination as being unreachable, and thus state for that connection 


1 Note that this is a slight departure from the Open Systems Interconnect (OSI) model, which separates the session 
and presentation layer from the application. Hence, with the Internet model, we end up with five layers, while the 
OSI model uses seven layers. 
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is removed. Hence, if a file transfer connection were broken, then the information accumulated 
at that point will have been lost, requiring that a new file transfer session be initiated. 

This 2-minute gap problem is directly related to the types of scenarios presented in Section 2. If 
a given scenario does not provide global coverage over both land and sea, then it is subject to the 
condition described above. In all of the detailed concepts we analyzed, this problem will exist. 

3.1.2 SCPS 

The Satellite Communications Protocol Standards (SCPS) is an ongoing effort that has set 
aggressive goals. It can be characterized as an all inclusive design to address a variety of 
perceived weaknesses of TCP/IP in support of satellite communications. In trying to accomplish 
its goals of high throughput with minimal disruption in traffic flow and user access, SCPS has 
defined a suite of protocols ranging from the application to the transport and down to the network 
layer. All of these SCPS protocols are derivatives of the standard TCP/IP suite and yet cannot 
peer directly with TCP/IP without a gateway to translate the protocol primitives (i.e., 
commands). 

An examination of the transport protocol of SCPS, referred to as SCPS-TP, shows that the 
designers use a Selective Negative Acknowledgment (S-NACK) to trigger the retransmission of 
data. This is in contrast to the standard TCP option of Selective Acknowledgment (SACK). 

Tests have shown that S-NACK can produce throughputs of approximately 30 percent faster than 
SACK. However, if one were to take into consideration the need to have SCPS-TP interact with 
standard TCP, then it can be argued that a substantial amount of buffer space will be needed to 
compensate for the disparate measures of throughput. Figure 3-1 is an example of an SCPS-TP 
connection between the mission payload and a gateway, and another connection between the 
gateway and a user located somewhere in the Internet. Thus, if there is a sustained rate of traffic 
from the payload to the gateway that is being forwarded at 30 percent or higher speeds (shown as 
the SCPS-TP connection), then the gateway has to be configured with enough buffer space to 
compensate for the slower speed of the standard TCP connection or data will be dropped. 

One means of addressing this problem is to insert an additional flow control message into SCPS- 
TP so that it will only transmit as fast as the standard STP connection can support. The irony in 
such an action is that the purported increase in throughput by an SCPS-TP connection is negated 
when standard TCP is used to complete the end-to-end communication between the user and the 
mission payload. 

3. 1.3 Vendor Support 

Unfortunately, the 2-minute gap problem is one that is not really addressed by the vendor 
community because so few terrestrial systems encounter it. Some vendors are working on 
“smart” web browsers and servers that can retain state for an extended period of time to 
compensate for broken connections due to acknowledgment timeouts. However, this is an 
example in which the solution is bound to one type of application. In addition, it is really a 
proprietary solution that may or may not be compatible with other vendors. 
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Figure 3-1. Interfacing SCPS to Standard internet 

One potential solution to the 2-minute gap problem is rather “low-tech” in nature and involves 
manual distribution of scheduled availability of mission payloads by ground stations. The 
measure of success, in this case, can be attributed to the total period of uninterrupted time that a 
LEO satellite is reachable by the user. From previous discussions with NASA, it was determined 
that a worst-case scenario may involve connectivity periods of just 90 seconds. Although this 
can be considered plenty of time for quick downloads of information, the ability to synchronize 
time over various distances can be problematic (e.g., how accurate is your wristwatch to the time 
displayed on your computer?). 

To address the 2-minute gap problem, it is likely that some combination of a gateway and 
customized solution (at least between the mission payload and the gateway) will need to be 
developed. 

3.2 IP Considerations 
3.2. 1 Mobile Host Problem 

Placing an IP address in a mission payload makes it become an IP node. Given that the payload 
is an end point (i.e., it does not act as a relay for other nodes) with applications loaded on it, the 
type of node is that of an IP host, as opposed to a router. The initial design of the Internet and the 
accompanying suite of protocols assumed a scenario in which hosts would be pretty much static 
and non-moving. More specifically, the designers did not envision hosts moving from one 
routing location to another while an end-to-end connection (e.g., a file transfer) took place. 

Hence, if a host moves from one routing location to another, all TCP connections will be broken. 
This is compounded with the need to track the movement of the host so that subsequent 
datagrams can be forwarded to it. 
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The purpose of MBP is to retain end-to-end connections as the mobile host (MH) moves from one 
logical IP routing location to another. Typically, these locations correlate to separate physical 
networks, which are termed subnetworks by the IP community. Routers are used to connect 
subnetworks, which can be the same or of different design (e.g., ATM, Ethernet, or SATCOM). 

Given that IP is a logical network that overlays physical networks, it is also possible to have two 
or more IP networks overlay the same physical network. This is a common practice with IP- 
over-Ethemet in that two sets of hosts are attached to the same Ethernet LAN. One set is 
assigned from the pool of lO.O.x.x IP addresses, while another set may be assigned from the pool 
of 198.1 16.x.x IP addresses. Even though the hosts from both sets are sending datagrams to the 
same physical network, they need a router to forward the traffic from one IP routing location 
(e.g., lO.O.x.x) to another location (e.g., 198.1 16.x.x). 

Included in the above model is the association of identity and location within an IP address. IP 
routers distribute information about where groups of address prefixes are located in the virtual 
Internet. In addition, the entire IP address (e.g., 198.1 16.63.2) identifies the host and, more 
importantly, is used in identifying an end-to-end TCP connection. 

When a host moves from one IP routing location to another, it must change its IP address. The 
tight association between locality and identity means that such a change will also break any 
existing end-to-end TCP connection made with that host. MIP sidesteps this problem by using 
encapsulation. Figure 3-2 shows an abstract example of a correspondent host (CH) sending 
traffic to the home network of the MH. The data traffic is then encapsulated and sent to the 
current location of the MH. Return traffic is then sent from the MH to the CH. This flow of 
traffic is called triangle routing. 


Home 

Agent 



Correspondent SPACECRAFT 

Host 

Figure 3-2. Example of a Correspondent Host Sending Traffic 
to the Home Network of the Mobile Host 


NASA/CR— 2001-21 1 198 


32 





The use of encapsulation allows the system to retain existing end-to-end connections as the MH 
moves to different locations. What is not shown in the figure is the discovery and registration 
process of the nodes (routers and hosts) used to update the current location of the MH. It is 
important that the speed by which a node moves to different locations does not eclipse the speed 
by which discovery and registration occur. Although there have been various simulation efforts 
concerning MIP, there has not been a definitive study as it relates to how fast an MH can travel. 
This is partly because the dynamics of where different nodes reside on the Internet together with 
various configuration parameters are hard to pin down. In addition, when an MH moves, there is 
the possibility that some IP traffic will be lost because it has been sent to the old location. This 
means that it will have to be retransmitted, and TCP will re-enter its slow start algorithm. 

In an attempt to produce an abstract rough order of magnitude, we attempt to characterize the 
maximum speed of an MH as the following: 

Max Speed < (0.33 seconds) + RTT(MH<->FA) + RTT(FA<->HA) + 2*RTT(CH<->MH ) 
where, 

RTT = Round Trip Time between two IP nodes (host or router) 

FA = Foreign Agent 

HA = Home Agent 

MH = Mobile Host 

CH = Correspondent Host. 

We decide on the above values based on the following. Discovery messages are sent on a 
periodic basis based on one-third of the lifetime field. The minimal value of this field is 
1 second; thus the shortest period of time in which a node can receive an advertisement message 
is 0.33 seconds. 

From this discovery, the MH sends a registration message to the FA, which in turn triggers a 
registration from the FA to the HA. We include the time it takes for two RTTs between the CH 
and the MH so that a possible retransmission message can be sent with additional traffic from 
either the CH or the MH. Again, we need to stress that the above is just a rough approximation 
that provides a minimum bound for establishing MIP-based connectivity. The important 
conclusion from the above is that, with minutes of contact time between a ground station and the 
payload, MIP can be configured to support the discovery and tracking of LEO satellites acting as 
MHs. 

3.2.2 Vendor Support 

A number of major vendors such as Cisco, Nokia, and Nortel are actively involved in the design 
and development of MIP. However, their full participation in terms of a number of COTS 
products being currently available is small or non-existent. This is an economic issue but can 
probably be traced to a lack of public demand. One interesting item to note is Sprint's plan to 
become an MIP provider. 

3.3 Full-Duplex Channel Requirements 

TCP/IP requires a full-duplex channel. For a basic application such as file transfer, all the data 
travels in one direction, and the other direction serves to carry only acknowledgments. In this 
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discussion we will assume this case. There is a simplified theoretical formula for calculating the 
data rate due to acknowledgments: 

R = M -f 40 


where, 

R = Ratio of data bytes sent to acknowledgment bytes received 
M = Maximum transmission unit (MTU) in bytes 
40 = Size of an acknowledgment in bytes. 

The MTU represents the maximum number of bytes that a physical network such as Ethernet can 
send as a unit or packet. The default MTU is 576 bytes. The typical MTU is 1,500 bytes, which 
is the size of an Ethernet packet. Note that at the Ethernet layer, the discussion is in terms of 
MTU, and at the TCP layer, the equivalent parameter is the maximum segment size. Optimum 
efficiency of packetization occurs when a single TCP segment fits exactly within a single 
physical network packet. 

Theoretically, for TCP the MTU can be set to ([2**16]— 40) = 65,496. Using this formula, we get 
65,496/40 or 1,637.4: 1 . Hence, for every 64K byte packet sent, 40 bytes are needed in return. 
This is actually the worst case scenario because, as more packets are sent, acknowledgments can 
be sent less frequently. In the next pass, an acknowledgment can be sent for the next two packets 
that were sent — that is, the sliding window takes effect. 

However, the above formula only applies for the MTU of an end-to-end path. When 
communicating from an arbitrary location on the Internet, the actual MTU used in the above 
equation is the smallest MTU that exists along the path between a user and the payload. One can 
expect that this will be 1,500, with a worst case of 576. For M=l,500, the result is R = 38: 1 . 

This discussion is significant for the case where a direct downlink occurs at the same physical 
location where the end-user PI is located. In this case, the PI and the earth station can be on the 
same physical network, where the MTU can be set at a known maximum value to optimize the 
value of R. This would allow a lower uplink data rate to be used and a lower terminal EIRP. 
When the earth station is not at the same location as the end-user, the end-user has no control 
over the MTU, and the worst case must be assumed. A higher uplink data rate would then be 
required. Alternatively, the network could be partitioned, as discussed in Section 2.1, and the 
MTU could be controlled within the partition. 

To confirm actual TCP behavior, SAIC ran a series of OPNET simulations of a simple TCP 
connection operating at 622 Mbps and assuming a bit error rate (at the TCP layer) of 10E-12 to 
determine what data rate would be required for the acknowledgment traffic. The assumptions 
used in the simulations are shown in Table 3-1. 
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Table 3-1. OPNET Simulation Assumptions 


| OPNET Scenario Settings J 

Client-Server Separation 

2,340 km (fixed) 

User Channel Bit Error Rate 

10E-12 (gaussian distributed noise) 

Physical Channel Data Rate 

622 Mbps 

Packet Generation Statistics 

Deterministic, Constant Rate 


TCP Parameter Settings 

Maximum Segment Size (bytes) 

Various: 8K-40 to 64K-40 

Receive Butter (bytes) 

Various: nx64K 

Receive Buffer Usage Threshold (of RCV BUFF) 

0.0 (OPNET default) 

Delayed ACK Mechanism 

Segment/Clock Based (OPNET default) 

Maximum ACK Delay (sec) 

0.200 (OPNET default) 

Fast Retransmit 

Enabled (OPNET default) 

Fast Recovery 

Enabled (OPNET default) 

Window Scaling 

Enabled 

Selective ACK (SACK) 

Disabled (OPNET default) 

Nagle’s SWA Avoidance 

Disabled (OPNET default) 

Kam’s Algorithm 

Enabled (OPNET default) 

Retransmission Threshold (sec) 

Attempts Based (OPNET default) 

Initial Retransmission Timeout (RTO) (sec) 

1.0 (OPNET default) 

Minimum RTO (sec) 

0,5 (OPNET default) 

Maximum RTO (sec) 

64 (OPNET default) 

RTT Gain 

0.125 (OPNET default) 

Deviation Gain 

0.25 (OPNET default) 

RTT Deviation Coefficient 

4.0 (OPNET default) 

Timer Granularity (sec) 

0.5 (OPNET default) 

Persistence Timeout (sec) 

1.0 (OPNET default) 

Output 

Time to transfer 1 00 Mbyte file minus time to 
transfer 10 Mbyte file 


The output of the simulation is the time to transmit a 100 MB file minus the time to transmit a 10 
MB file. This gives the time to transmit a 90 MB file without the transient condition at the start 
of file transfer due to the slow start congestion algorithm. This allows one to calculate the 
average data rate during the steady state portion of the transmission. The results are shown in 
Table 3-2. The best time observed is 1.21 seconds. This corresponds to a data rate of 595 Mbps. 
The lowest data rate for the acknowledgment channel that allows for a 1.21 second transfer time 
is 256 Kbps. This particular simulation was run with a setting for the TCP maximum segment 
size of 65,496 octets, the maximum allowed, and a receive buffer (window) size of at least 32 
times 65,536 octets (2.097 152 MB), that is, a scale factor of 32 under the window scaling option. 
This means the receive buffer allocation must be set to at least 2,097,152 bytes in the TCP 
configuration file. 

This simulation indicates that the ratio of the data packet data rate to the acknowledgment packet 
data rate can be as high as 2,324 under optimum conditions. 
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Table 3-2. OPNET Simulation Results 
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25.07 
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1.21 

1.21 

1.21 
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3.28 
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3.15 

3.41 
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16.14 
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x256 

1.22 

—E 

1.22 

1.46 

2.93 
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23.48 
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231.23 

xl 28 

1.22 

1.22 

1.22 

1.62 

3.25 
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26.14 
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247.23 

32728 x64 

1.22 

1.22 

1.22 

1.71 

3.43 

6.90 

13.80 

27.62 

59.07 

121.29 

272.51 

x32 

1.22 

1.22 

1.22 

1.74 

3.49 

7.06 

14.12 

28.24 

60.54 

117.49 

285.63 

x8 

2.75 

2.77 

2.83 

2.95 

3.64 

7.37 

14.94 

30.70 

61.40 

122.80 

304.45 

; 

1.22 

1.22 

1.46 

2.93 

5.86 

11.71 

23.44 

47.48 

99.09 

203.77 

460.83 

x128 

1.22 

1.22 

1.62 

3.25 

6.51 

13.01 

26.03 
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109.57 

226.17 
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1.22 

1.22 
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3.41 
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13.66 

27.41 
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115.97 
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1.22 

1.22 

1.73 

3.46 

6.96 

13.84 

27.85 

55.36 

117.08 

242.57 


li§!: .*0 \ 

2.62 

2.65 

2.72 

3.54 

7.12 

14.15 

29.04 

56.60 

116.16 

278.40 

584.12 

X256 

IKE3 

ima 

2.94 
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47.32 
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198.09 
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X128 
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1.62 

3.26 

6.52 

13*04 

26.07 

52.62 

105.24 
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8152 x64 

1.22 

1.70 

3.42 

6.84 

13.68 

27.41 

55.41 

111.12 

232.29 


tmm 

x32 

1.22 

1.73 

3.46 

6.92 

13.84 

27.68 

55.36 

113.58 

234.45 

473.93 

iim 

x8 













Forward channel 622Mbits/sec 
One way delay 0.0078sec (each way) 
Data Size 90M Bytes 


Note that for a file size of 90 MB and a bit error rate of 10E-I2, the probability of a single error 
is very low. For larger files, the probability of an error increases. When an error occurs, an 
entire segment must be retransmitted. Because the segments are so large, this would result in a 
degradation of the average throughput. Thus, the very high ratio of 2,324 is obtained at the 
expense of degraded throughput for large files. 

3.4 Link Layer 

The Operating Missions as Nodes on the Internet (OMNI) project at Goddard Space Flight 
Center (GSFC) is designed to demonstrate the use of standard IP for space communication 
systems. Recent experiments have been performed with the UoSAT-12 spacecraft. The work is 
focused on defining the communication architecture for future NASA missions. The use of 
standardized communications technology for spacecraft both simplifies design and permits the 
exploitation of commercial telecommunication advances. 

The rationale for the use of IP is that it provides a basic standardized mechanism for end-to-end 
communications among applications across a network. A spacecraft was selected that could 
support high-level data link control (HDLC) framing in hardware: the UoSAT-12. This framing 
was chosen for the link-level protocol on the space to ground link because of its near universal 
use in terrestrial networking. This allowed for simple, straightforward interfacing with existing 
routers. Interoperability was ensured by encapsulating the IP over frame-relay/HDLC. Thus, 
only software changes were required to adapt the satellite to use IP. Store-and-forward 
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commanding and data delivery, using simple mail transfer protocol (SMTP), were scheduled to 
be demonstrated in the latter part of year 2000. 

The OMNI project results discuss the success and feasibility of exploiting the capabilities of the 
HDLC and provide examples of the HDLC/frame-relay/IP packet formats as successfully used in 
the experiment. The feasibility of using IP protocols aboard small LEO spacecraft appears to be 
very low risk [RASH]. 
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4. RESULTS AND CONCLUSIONS 


4.1 Comparison of Concepts 

In this section, we summarize the results of our analysis by comparing the throughput and cost 
estimates that were derived for each concept. The throughput comparison is shown in Tables 4-1 
and 4-2, and the cost comparison is shown in Table 4-3. 


Table 4-1. Throughput Comparison, ISS Orbit 



; ■ ; ■ ;; ■; 

. : 

•/ : i ; : ; 



uommerctat 

Commercial 


: != t iP !!': : iv 5’ .•=: 1 : % j : t ;• r : f I % 

TDRSSSA, 

KuBand 

04 Single 
Beam 

D4 Dual 
Beam 

Hybrid 

Detail^ 

a*q«KI 

Downlink 

Service 

A-o&rta 

Downlink 

Service 

uommeraai 

MSSNGSO 

StarLynx 

Antenna beam scan (°) 


50 

42 

50 

50 

50 

70* 


Return link data rate (Mbps) 

50 

622 

1,244 

622 

622 

300 

300 

8 

Data transfer time relative to OC12 

12 

1 

0.5 

1 

1 

2 

2 

78 

Average contact time per day (sec) 

43,200 

337 

178 

337 

337 

337 

2,755 

69,120 

Throughput per day (Gbits) 

2,160 

210 

221 

210 

210 

101 

827 

553 


‘Spacecraft antenna scan angle needed to match earth station with a 5° elevation angle 
Note: Earth station located at Kl Sawyer AFB 


Table 4-2. Throughput Comparison, Polar Orbit 
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‘Spacecraft antenna scan angle needed to match earth station with a 5° elevation angle 
Note: Earth station located at Spitzbergen 


Table 4-3. Cost Comparison 
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4.2 Conclusions 


For a layered communications architecture model, the distinguishing characteristics of the end- 
to-end system concepts reside primarily at the physical layer and link layer. We therefore studied 
a set of alternative link layer architectures. These consisted of two basic architectures, direct and 
relay, and combinations of these. The combinations may be constructed to achieve the different 
scenarios described in the Statement of Work. These two basic architectures were analyzed 
separately in terms of three fundamental metrics: contact time, throughput, and cost. The other 
architectures can be characterized in terms of the metrics of two basic ones. 

4.2. 1 Direct Architecture 

The asymmetric full duplex direct link architecture using TCP/IP is feasible using the D3 
millimeter wave downlink system developed by NASA GRC augmented by an uplink system 
with a very modest data rate requirement. The need for a duplex link is driven by the 
requirement for using TCP. 

The throughput of the D4 system can be increased roughly in linear proportion by deploying 
earth stations at multiple sites. There is no apparent technical obstacle to maintaining a virtual 
link connection as a spacecraft passes between contiguous earth station coverage regions. Gaps 
between the regions may also be tolerated as long as the gap in time does not exceed the TCP 
timeout parameter. 

The optimum D4 earth station locations are a function of mission specifics. They depend on the 
mission’s specific output requirement, the degree of latency that can be tolerated, and the orbital 
inclination, among other things. For a given mission, the optimum location is close to the 
highest latitude of the spacecraft ground track. 

Distributions of stations within the continental United States for serving a mission, such as the 
ISS, were studied, and a relatively small number of stations, such as four, can provide almost full 
continental coverage. We did not attempt to find the best locations for global coverage. 

For the ISS case, Table 4-1 shows that a network of approximately 10 D4 earth stations could 
achieve the same daily throughput as TDRSS under the assumptions shown. The cost table. 

Table 4-3, shows that this could be accomplished at a significantly lower per-minute cost and 
per-bit cost. Note, however, that the cost picture is complicated by the one-time set-up charge of 
$150,000 per mission that is a feature of current commercial LEO services. This cost would 
presumably decline as the number of missions using the service increases. 

Comparing the D4 system with the existing X-band technology, the D4 system obviously has 
higher throughput when compared with an equivalent X-band system having the same antenna 
scan angles. However, the existing X-band terminals, including NASA’s Earth Observing 
System (EOS) polar ground stations, have scan angles of 5° elevation above the horizon. When 
operating with a spacecraft antenna that can match the earth station scan, a much higher 
throughput can be achieved. This result is represented in column 8 of Table 4- 1 . 

For the polar case. Table 4-2 shows that the throughput improves by a factor of 5 due to the 
higher frequency of contacts. The comparison with TDRSS, therefore, is more favorable. The 
comparison with the X-band earth stations again depends on the scan angle that is assumed. 
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The D4 system would be especially efficient in serving polar missions because one or two earth 
stations near the pole can obtain a high amount of contact time, as well as a high frequency of 
contacts. The utility of polar sites is further multiplied by the fact that most high data rate LEO 
missions are polar orbiters. 

As the results show, the throughput per earth station can be substantially improved by extending 
the angle that the ground and spacecraft antennas can scan. Because contact time is a non-linear 
function of scan angle, a relatively modest increase in scan angle can provide a large increase in 
contact time. However, this benefit must be traded against the need for increased spacecraft 
EIRP to compensate for the increased slant range. 

4.2.2 Relay Architecture 

A D4 direct link system could be supplemented by a space relay link system. We assessed 
commercial satellite communications technologies and concluded that there are no services that 
meet the minimum criteria for a Ka-band, broadband MSS for NASA LEO/MEO mission 
platforms within the next 5 years. In the longer term, many MEO systems have been proposed 
that would improve the coverage to global or near-global coverage. However, most of these 
systems will be FSS. There is also uncertainty about the likelihood of deploying these systems. 

One proposed system, Hughes StarLynx, meets all of the criteria except that it will not be 
available by 2005. It is an MSS, operates at V-band, and has both GEO and MEO constellations. 
The 8 Mbps data rate is relatively low, using the 2-foot diameter VSAT terminals to be designed 
for the typical user. The low data rate is compensated for by the essentially global coverage. It 
seems likely that higher data rates would be available should the service ever be deployed. 
However, we consider the likelihood of deployment to be low. 

In estimating costs, it was found that the broadband satellite services will be priced competitively 
with terrestrial services so that, for a given data rate, the cost per bit should be roughly 
comparable. However, as in terrestrial services, there will be a steep discounting curve as a 
function of data rate. 

4.2.3 Hybrid and Combination Architectures 

Two other architectures were described: the hybrid and combination architectures. The hybrid 
architecture consists of a direct downlink using the D3 system and a space relay service for 
transporting the TCP acknowledgments back to the spacecraft. This architecture makes sense for 
spacecraft carrying a TDRSS S-band transceiver, for example. The acknowledgments could be 
carried by the S-band link. 

Among the possible combined architectures, one stands out as effective and practical. This is a 
“dual-mode” combination of a simplex high data rate direct downlink, using UDP instead of 
TCP, combined with a low data rate, full duplex TCP/IP link using a SATCOM service such as 
Inmarsat or TDRSS MA. The high data rate link would be used for returning latency-tolerant 
instrument data from the spacecraft. The low data rate link would be used for real-time 
interactive commands between the PI and the spacecraft. 
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Acknowledgment 

AFB 

Air Force Base 
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Asynchronous transfer mode 

BSS 

Broadcast Satellite Service 

CEO 

Chief Executive Officer 

CH 

Correspondent host 

CONUS 

Continental United States 

COTS 

Commercial off-the-shelf 

D3 

Direct Data Distribution 

D4 

Duplex Direct Data Distribution 

DARO 

Defense Airborne Reconnaissance Office 
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Direct Broadcast Satellite 
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Domain Name Service 

EESS 

Earth exploration satellite service 

EHF 

Extremely high frequency 

E1RP 

Equivalent Isotropic Radiated Power 

EOS 

Earth Observing System 

FA 

Foreign Agent 

FAA 

Federal Aviation Administration 

FCC 

Federal Communications Commission 

FDP 

Forward Data Path 

FSS 

Fixed Satellite Service 

GEO 

Geosynchronous orbit 

GRC 

Glenn Research Center 

GSFC 

Goddard Space Flight Center 

GSO 

Geostationary orbit 

HA 

Home Agent 

HCI 

Hughes Communication Inc. 

HDLC 

High-level data link control 

ICMP 

Internet Control Message Protocol 

IOA 

Integrated Operations Architecture 

IP 

Internet Protocol 

ISL 

Inter-satellite link 

ISP 

Internet service provider 

ISS 

International Space Station 

ITU 

International Telecommunications Union 
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LAN 

Local area network 

LEO 

Low earth orbit 

MEO 

Medium earth orbit 

MH 

Mobile Host 

MIP 

Mobile IP 

MSS 

Mobile Satellite Service 

MTU 

Maximum transmission unit 

NASA 

National Aeronautics and Space Administration 

NGSO 

Non-geostationary orbit 

NTIA 

National Telecommunications and Information Administration 

OMNI 

Operating Missions as Nodes on the Internet 

OSI 

Open Systems Interconnect 

PI 

Principal investigator 

RDP 

Return Data Path 

RDSS 

Radio-determination satellite service 

RF 

Radio frequency 

RTO 

Retransmission timeout 

RTT 

Round trip time 

SACK 

Selective acknowledgment 

SAIC 

Science Applications International Corporation 

SATCOM 

Satellite communication 

SCPS 

Satellite Communications Protocol Standards 

SCPS-TP 

SCPS Transport Protocol 

SMTP 

Simple mail transfer protocol 

S-NACK 

Selective negative acknowledgment 

SOS 

Space Operations Service 

SRS 

Space Research Service 

STK 

Satellite Tool Kit 

TCP 

Transmission Control Protocol 

TDRSS 

Tracking and Data Relay Satellite System 

TT&C 

Telemetry, Tracking, and Command 

UAV 

Unmanned aerial vehicle 

UDP 

User Datagram Protocol 

USN 

Universal Space Network 

VS AT 

Very small aperture terminal 

WAN 

Wide area network 
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